REMARKS 



In response to the outstanding Office Action of September 6, 2007, in connection with 
the above-identified application, the following remarks are respectfully submitted. Favorable 
consideration of pending Claims 1-30, 48-51 and 58 is respectfully requested. Claims 31, 47, and 
52-57 have been previously withdrawn. 

Claims 1-30, 48-51 and 58 were rejected as failing to comply with the enablement 
requirement set forth in under 35 U.S.C. §112 1)1. Examiner applied the factors presented by In 
re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988) and concluded that a person 
having ordinary skill in the art would have to perform undue experimentation in order to make 
and use the invention, and therefore failed the statutory enablement requirement. 

Applicants respectfully traverse this rejection, and further request that this rejection be 
reconsidered and withdrawn for at least the following two reasons: (1) because the rejection 
does not fully consider knowledge properly imputed to a person having ordinary skill in the art 
per current case law and (2) because the rejection improperly requires source code in the 
specification itself as an enabling disclosure, examiner misapprehends the enablement 
requirement. Accordingly, the Applicant respectfully submits that the facts of the present case 
have not been correctly applied to the Wands factors, and therefore do not establish undue 
experimentation. 



Enablement Requires Imputing the Knowledge of a Skilled Programmer 

The Court of Appeals for the Federal Circuit (hereafter "CAFC") has held that the level of 
one of ordinary skill for electrical/computer inventions is a skilled programmer. Northern 



Telecom Inc. v. Datapoint Corp., 15 USPQ2d 1321 at 1330. Therefore, all the knowledge 
imputed to a skilled programmer, including but not limited to knowledge of XML, tags, and code 
generation, may be considered in enablement, not merely the explicit disclosure of the 
application's specification. 

Applicant is not Required to Provide Source Code to Prevent Undue Experimentation 

As stated above, regarding electrical/computer inventions (unlike the biotech invention 
in Wands), the CAFC has held that when the invention relates to a computer program, 
enablement is determined from the viewpoint of a skilled programmer, going on to state: 



In assessing any connputer-related Invention, it must be 
remembered that the programming Is done In a computer 
language. The computer language is not a conjuration of some 

black art, it is simply a highly structured language [T]he 

conversion of a complete thought (as expressed in English and 
mathematics, i.e. the known input, the desired output, the 
mathematical expressions needed and the methods of using 
those expressions) into a language a machine understands is 
necessarily a mere clerical function to a skilled programmer. 
Northern Telecom inc. v. Datapoint Corp., 15 USPQ2d 1321 at 
1330 (emphasis added). 



Therefore, an application of a computer invention that has no or limited source code is 
not unenabled under 35 U.S.C. §112 HI without an additional deficiency. 
Wands Factors: 

Applicant observes that Wands was decided in the context of a biotech patent 
application. The present application should be considered in terms of the electrical/computer 
arts. Applicant notes that the standard is not whether experimentation is required to practice 
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the invention, but ratiier if such experimentation is "undue." Applying the facts of the present 
case to the Wands factors, each of the factors either lowers the amount of disclosure required 
for enablement or extends the latitude of reasonableness for experimentation. Applicant 
responds to each of the Wands factors arguments in order presented by Examiner: 

a) Breadth: Applicant respectfully submits that Breadth lowers the amount of disclosure 
necessary to enable a claim. Therefore, if, as asserted in the rejection, the rejected claims 
are broad, this standard has been misapplied in the rejection. 

Additionally, Applicant submits that the rejection's comments regarding the Applicant's 
Appendix B from April 28, 2008 substituted an example in a definition for the definition 
itself. Appendix B is a technical definition of the term "layer" which happened to use the 
OSI model as an example of a layered architecture. It also used TCP/IP as an example of a 
two-layer set of programs. However, Applicant is not asserting that all layered architectures 
are directed to networl< protocol stacks. 

Applicant submits that the rejected claims relates to an object-oriented software 
development environment in which takes advantage of the technique of "layers of 
abstraction" in which upper layers are implemented in terms of layers underneath them. 
This technique applies not only to network stacks, but also operating systems, and of course 
application frameworks. 

In stating that the "invention was implemented as 'GEtheSource'", the rejection 
misquotes Applicant. Rather, as set forth in Applicant's statement of..., GEtheSource was 
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implemented using tlie invention. GEtlieSource is not an object-oriented development 
environment, but rather is a web application created in part by the invention. 

The nature of the invention: While the rejected claims may be implemented in the context 
of a software development system, it is noted that with regards to software, including in 
software development systems, experimentation in the fornn of iterating coding and 
debugging cycles is weli-known, and expected by ordinary practitioners in order to practice 
a software invention. Software commonly is developed from general design specifications, 
some less detailed than Applicant's patent specification, but no less enabling. Therefore the 
standard of what constitutes unreasonable and therefore undue experimentation is lower, 
and the amount of disclosure necessary to enable the invention is lessened. 

The state of the prior art: Assuming, arguendo, that object oriented software development 
platforms have been in existence several years before the present application was filed, as 
asserted in the rejection, this factor actually militates in favor of Applicant because more 
knowledge about object oriented software development platforms may be imputed to a 
person having ordinary skill in the art. Therefore the standard of what constitutes 
unreasonable and therefore undue experimentation is lower, and the amount of disclosure 
necessary to enable the invention is lessened. 

The level of one of ordinary skill: Applicant respectfully submits that the rejection does not 
correctly state the standard for the level one of ordinary skill. The level of one of ordinary 
skill is not merely self-referential, but rather must be considered within the context of the 
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art. As stated above, here the level of one of ordinary skill for electrical/computer 
inventions is a skilled programnner. 

e) The level of predictability in the art: Assuming, arguendo, that distributed systems and 
software generation is generally deterministic and therefore more predictable than 
biotechnology which Wands was directed to, as set forth in the rejection, this line of 
reasoning actually militates in favor of less specification rather than more specification. 
That is, because the electrical/computer arts are arguably more predictable, persons having 
ordinary skill in the art will require less, rather than more direction from Applicant. 

f) The amount of direction provided by the inventor: Applicant respectfully submits that this 
factor is misapplied in the rejection by equating the specification with providing source code 
showing an actual implementation. The rejection states that because the pending 
application has limited source code in the specification, that the application is not enabled. 
The rejection goes on to call out the following examples: (1) login prompt on p. 57, (2) 
JavaScript login function in Table 5, (3) object abstracts in Tables 18-30, (4) HTML login 
source code snippet, (5) XIVIL elements in Table 1, and (6) sample XML file for an asset 
catalog program in Table 2. However, as stated above. Applicant is not required to submit 
full source code. Still, for the sake of completeness, Applicant will address each of the cited 
source code examples as follows: 

(1) the p. 57 login prompt is a sample input into the invention; (2) the JavaScript 
login in Table 5 is a sample output of the invention, (3) the object abstracts of Tables 
18-30 list the specific custom tags and HTML extensions necessary to enable 
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automatic generation of source code, (4) the sample HTML login in page 94 is a 
sample input for localization, (5) the XML elements in Table 1 are reiterated (and in 
fact can be imputed to a person having ordinary skill in the art) to describe what 
tags and attributes require for XML compliance - since the invention comprises XML 
extended tags and attributes, and (6) the sample asset catalog XML file in Table 2 
shows how the invention maps commands and views to interactions. The rejection 
objects to the sample code in Table 5 not referencing any other portion of the 
specification - but indeed it cannot, because it is just exemplary source code of 
output of the inventive concept. As stated above, implementations are not 
required. But far from not providing examples of the "implementations of the 
layers or domains" as required by the rejection. Applicant has provided numerous 
examples. 

g) The existence of working examples: The rejection states that Applicant has "provided no 
working examples to the Office for review." However, Applicant respectfully submits that 
the standard is not whether Applicant provides a working example for review, but rather if a 
working example exists. As acknowledged in the rejection. Applicant has provided the office 
notice of "GEtheSource" which is "a web-based asset management application" that 
"incorporates logic that is related to the subject matter described in the present 
application" in remarks dated September 12, 2005. As stated above, GEtheSource is not the 
invention, but rather an output of the invention. To date, the Office has notified Applicant 
that previous 37 CFR 1.105 Requirement for Information is moot. Office Communication 
January 10, 2008. 
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h) The quantity of experimentation needed to make or use tlie invention based on tlie 
content of tlie disclosure: Applicant respectfully submits that the standard is not the 
quantity of experimentation to make or use the invention based on the content of the 
disclosure, but rather the quantity of experimentation to make or use the invention. If the 
standard were to be limited to the content of the disclosure, Applicant would be required to 
provide information well known in the art resulting in allegedly unenabled claims. For this 
reason, "A patent need not teach, and preferably omits, what is well known in the art." In re 
Buchner, 929 F.2d 660, 661, 18 USPQ2d 1331, 1332 (Fed. Cir. 1991); Hybritech, Inc. v. 
Monoclonal Antibodies, Inc., 802 F.2d 1367, 1384, 231 USPQ81, 94 (Fed. Cir. 1986), cert, 
denied, 480 U.S. 947 (1987); and Lindennann Maschinenfabrik GMBH v. American Hoist & 
Derricic Co., 730 F.2d 1452, 1463, 221 USPQ481, 489 (Fed. Cir. 1984). 
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Conclusion 



Applicant respectfully requests that Examiner withdraw 35 U.S.C. §112 1)1 enablennent 
rejection because, among other reasons, taking into account a skilled programmer's imputed 
knowledge of XML, tags, and code generation, provides sufficient information to practice the 
invention; because the status of software broadens the latitude of reasonable experimentation; 
and because explicit source code is not required to enable a software patent application,. 

Applicant respectfully submits that Claims 1-30, 48-51 and 58 are now in condition for 
allowance. Applicant respectfully requests prompt allowance of the subject application. If any 
issue remains unresolved that would prevent allowance of this case, the Examiner is requested 
to contact the undersigned attorney to resolve the issue. 



Respectfully Submitted, 



Lee & Hayes, pile 





a)avid S. Lee 
Lee & Hayes, PLLC 
Reg. No. 38,222 
(206) 315-7912 
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